Request for Comment (RFC) 2547 bis provides out a virtual private network (VPN) model that uses border gateway protocol (BGP) to distribute VPN routing information across the service provider's backbone and Multi-protocol label switching (MPLS) to forward VPN traffic from one VPN site to another. RFC 2547 bis defines a VPN as a collection of policies, and these policies control connectivity among a set of sites. A customer site is connected to the service provider network by one or more ports, where the service provider associates each port with a VPN routing table. RFC 2547 bis calls the VPN routing table as a VPN routing and forwarding (VRF) table. A customer edge (CE) device provides customer access to the service provider network over a data link to one or more provider edge (PE) routers. The CE device can be a host, a Layer 2 switch, or more commonly, an IP router that establishes an adjacency with its directly connected PE routers. After the adjacency is established, the CE router advertises the site's local VPN routes to the PE router and learns remote VPN routes from the PE router. After learning local VPN routes from CE routers, a PE router exchanges VPN routing information with other PE routers using IBGP.
A route distinguisher (RD) is an identifier that is used to differentiate IP addresses or IPv4 prefixes of a VPN from another because customers may not use globally unique IP addresses. RFC 2547 bis constrains the distribution of routing information among PE routers by the use of route filtering based on a route target (RT) attribute, which is one of the BGP extended community attributes. Route targets include import targets and export targets. The import target of a site governs which sites' route update information or advertisement it will accept; the export target of the site specifies what import target the sites it advertises to should include.
An enterprise's VPN may be configured in a hub-and-spoke topology where the firewall is the hub through which all traffic is routed. The hub site's VRF table is configured with an export target=hub and an import target=spoke. The VRF table at the hub site distributes all of the routes in its VRF table with a hub attribute that causes the routes to be imported by the spoke sites. The VRF table at the hub site imports all remote routes with a spoke attribute. The VRF table at each spoke site is configured with an export target=spoke and an import target=hub. The VRF table at each spoke site distributes its routes with a spoke attribute, which causes the routes to be imported by the hub site, but dropped by other spoke sites. The VRF table at a spoke site imports only routes with a hub attribute, which causes its VRF table to be populated only with routes advertised by the hub site.
In conventional VPNs, policy-based routing around the firewall in the huband-spoke topology requires either the knowledge of the IPv4 prefix or the use of at least two router ports in order to route packets to the spokes from the hub. The reliance using the IP address is tedious and labor intensive, and using an extra router port is inefficient and costly.